home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / bbs / rfc / rfcxxxx_8.lha / rfc1701 < prev    next >
Text File  |  1995-07-26  |  15KB  |  452 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           S. Hanks
  8. Request for Comments: 1701                               NetSmiths, Ltd.
  9. Category: Informational                                            T. Li
  10.                                                             D. Farinacci
  11.                                                                P. Traina
  12.                                                            cisco Systems
  13.                                                             October 1994
  14.  
  15.  
  16.                   Generic Routing Encapsulation (GRE)
  17.  
  18. Status of this Memo
  19.  
  20.  
  21.    This memo provides information for the Internet community.  This memo
  22.    does not specify an Internet standard of any kind.  Distribution of
  23.    this memo is unlimited.
  24.  
  25. Abstract
  26.  
  27.    This document specifies a protocol for performing encapsulation of an
  28.    arbitrary network layer protocol over another arbitrary network layer
  29.    protocol.
  30.  
  31. Introduction
  32.  
  33.    A number of different proposals [RFC 1234, RFC 1226] currently exist
  34.    for the encapsulation of one protocol over another protocol. Other
  35.    types of encapsulations [RFC 1241, SDRP, RFC 1479] have been proposed
  36.    for transporting IP over IP for policy purposes. This memo describes
  37.    a protocol which is very similar to, but is more general than, the
  38.    above proposals.  In attempting to be more general, many protocol
  39.    specific nuances have been ignored.  The result is that this proposal
  40.    is may be less suitable for a situation where a specific "X over Y"
  41.    encapsulation has been described.  It is the attempt of this protocol
  42.    to provide a simple, general purpose mechanism which is reduces the
  43.    problem of encapsulation from its current O(n^2) problem to a more
  44.    manageable state.  This proposal also attempts to provide a
  45.    lightweight encapsulation for use in policy based routing.  This memo
  46.    explicitly does not address the issue of when a packet should be
  47.    encapsulated.  This memo acknowledges, but does not address problems
  48.    with mutual encapsulation [RFC 1326].
  49.  
  50.    In the most general case, a system has a packet that needs to be
  51.    encapsulated and routed.  We will call this the payload packet.  The
  52.    payload is first encapsulated in a GRE packet, which possibly also
  53.    includes a route.  The resulting GRE packet can then be encapsulated
  54.    in some other protocol and then forwarded.  We will call this outer
  55.  
  56.  
  57.  
  58. Hanks, Li, Farinacci & Traina                                   [Page 1]
  59.  
  60. RFC 1701          Generic Routing Encapsulation (GRE)       October 1994
  61.  
  62.  
  63.    protocol the delivery protocol. The algorithms for processing this
  64.    packet are discussed later.
  65.  
  66. Overall packet
  67.  
  68.    The entire encapsulated packet would then have the form:
  69.  
  70.                   ---------------------------------
  71.                   |                               |
  72.                   |       Delivery Header         |
  73.                   |                               |
  74.                   ---------------------------------
  75.                   |                               |
  76.                   |       GRE Header              |
  77.                   |                               |
  78.                   ---------------------------------
  79.                   |                               |
  80.                   |       Payload packet          |
  81.                   |                               |
  82.                   ---------------------------------
  83.  
  84. Packet header
  85.  
  86.    The GRE packet header has the form:
  87.  
  88.        0                   1                   2                   3
  89.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  90.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  91.       |C|R|K|S|s|Recur|  Flags  | Ver |         Protocol Type         |
  92.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  93.       |      Checksum (optional)      |       Offset (optional)       |
  94.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  95.       |                         Key (optional)                        |
  96.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  97.       |                    Sequence Number (optional)                 |
  98.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  99.       |                         Routing (optional)
  100.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  101.  
  102.       Flags and version (2 octets)
  103.  
  104.       The GRE flags are encoded in the first two octets.  Bit 0 is the
  105.       most significant bit, bit 15 is the least significant bit.  Bits
  106.       13 through 15 are reserved for the Version field.  Bits 5 through
  107.       12 are reserved for future use and MUST be transmitted as zero.
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Hanks, Li, Farinacci & Traina                                   [Page 2]
  115.  
  116. RFC 1701          Generic Routing Encapsulation (GRE)       October 1994
  117.  
  118.  
  119.       Checksum Present (bit 0)
  120.  
  121.       If the Checksum Present bit is set to 1, then the Checksum field
  122.       is present and contains valid information.
  123.  
  124.       If either the Checksum Present bit or the Routing Present bit are
  125.       set, BOTH the Checksum and Offset fields are present in the GRE
  126.       packet.
  127.  
  128.       Routing Present (bit 1)
  129.  
  130.       If the Routing Present bit is set to 1, then it indicates that the
  131.       Offset and Routing fields are present and contain valid
  132.       information.
  133.  
  134.       If either the Checksum Present bit or the Routing Present bit are
  135.       set, BOTH the Checksum and Offset fields are present in the GRE
  136.       packet.
  137.  
  138.       Key Present (bit 2)
  139.  
  140.       If the Key Present bit is set to 1, then it indicates that the Key
  141.       field is present in the GRE header.  Otherwise, the Key field is
  142.       not present in the GRE header.
  143.  
  144.       Sequence Number Present (bit 3)
  145.  
  146.       If the Sequence Number Present bit is set to 1, then it indicates
  147.       that the Sequence Number field is present.  Otherwise, the
  148.       Sequence Number field is not present in the GRE header.
  149.  
  150.       Strict Source Route (bit 4)
  151.  
  152.       The meaning of the Strict Source route bit is defined in other
  153.       documents.  It is recommended that this bit only be set to 1 if
  154.       all of the the Routing Information consists of Strict Source
  155.       Routes.
  156.  
  157.       Recursion Control (bits 5-7)
  158.  
  159.       Recursion control contains a three bit unsigned integer which
  160.       contains the number of additional encapsulations which are
  161.       permissible.  This SHOULD default to zero.
  162.  
  163.       Version Number (bits 13-15)
  164.  
  165.       The Version Number field MUST contain the value 0.  Other values
  166.       are outside of the scope of this document.
  167.  
  168.  
  169.  
  170. Hanks, Li, Farinacci & Traina                                   [Page 3]
  171.  
  172. RFC 1701          Generic Routing Encapsulation (GRE)       October 1994
  173.  
  174.  
  175.       Protocol Type (2 octets)
  176.  
  177.       The Protocol Type field contains the protocol type of the payload
  178.       packet.  In general, the value will be the Ethernet protocol type
  179.       field for the packet.  Currently defined protocol types are listed
  180.       below.  Additional values may be defined in other documents.
  181.  
  182.       Offset (2 octets)
  183.  
  184.       The offset field indicates the octet offset from the start of the
  185.       Routing field to the first octet of the active Source Route Entry
  186.       to be examined.  This field is present if the Routing Present or
  187.       the Checksum Present bit is set to 1, and contains valid
  188.       information only if the Routing Present bit is set to 1.
  189.  
  190.       Checksum (2 octets)
  191.  
  192.       The Checksum field contains the IP (one's complement) checksum of
  193.       the GRE header and the payload packet.  This field is present if
  194.       the Routing Present or the Checksum Present bit is set to 1, and
  195.       contains valid information only if the Checksum Present bit is set
  196.       to 1.
  197.  
  198.       Key (4 octets)
  199.  
  200.       The Key field contains a four octet number which was inserted by
  201.       the encapsulator.  It may be used by the receiver to authenticate
  202.       the source of the packet.  The techniques for determining
  203.       authenticity are outside of the scope of this document.  The Key
  204.       field is only present if the Key Present field is set to 1.
  205.  
  206.       Sequence Number (4 octets)
  207.  
  208.       The Sequence Number field contains an unsigned 32 bit integer
  209.       which is inserted by the encapsulator.  It may be used by the
  210.       receiver to establish the order in which packets have been
  211.       transmitted from the encapsulator to the receiver.  The exact
  212.       algorithms for the generation of the Sequence Number and the
  213.       semantics of their reception is outside of the scope of this
  214.       document.
  215.  
  216.       Routing (variable)
  217.  
  218.       The Routing field is optional and is present only if the Routing
  219.       Present bit is set to 1.
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Hanks, Li, Farinacci & Traina                                   [Page 4]
  227.  
  228. RFC 1701          Generic Routing Encapsulation (GRE)       October 1994
  229.  
  230.  
  231.       The Routing field is a list of Source Route Entries (SREs).  Each
  232.       SRE has the form:
  233.  
  234.     0                   1                   2                   3
  235.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  236.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  237.    |       Address Family          |  SRE Offset   |  SRE Length   |
  238.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  239.    |                        Routing Information ...
  240.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  241.  
  242.    The routing field is terminated with a "NULL" SRE containing an
  243.    address family of type 0x0000 and a length of 0.
  244.  
  245.    Address Family (2 octets)
  246.  
  247.    The Address Family field contains a two octet value which indicates
  248.    the syntax and semantics of the Routing Information field.  The
  249.    values for this field and the corresponding syntax and semantics for
  250.    Routing Information are defined in other documents.
  251.  
  252.    SRE Offset (1 octet)
  253.  
  254.    The SRE Offset field indicates the octet offset from the start of the
  255.    Routing Information field to the first octet of the active entry in
  256.    Source Route Entry to be examined.
  257.  
  258.    SRE Length (1 octet)
  259.  
  260.    The SRE Length field contains the number of octets in the SRE.  If
  261.    the SRE Length is 0, this indicates this is the last SRE in the
  262.    Routing field.
  263.  
  264.    Routing Information (variable)
  265.  
  266.    The Routing Information field contains data which may be used in
  267.    routing this packet.  The exact semantics of this field is defined in
  268.    other documents.
  269.  
  270. Forwarding of GRE packets
  271.  
  272.    Normally, a system which is forwarding delivery layer packets will
  273.    not differentiate GRE packets from other packets in any way.
  274.    However, a GRE packet may be received by a system.  In this case, the
  275.    system should use some delivery-specific means to determine that this
  276.    is a GRE packet.  Once this is determined, the Key, Sequence Number
  277.    and Checksum fields if they contain valid information as indicated by
  278.    the corresponding flags may be checked.  If the Routing Present bit
  279.  
  280.  
  281.  
  282. Hanks, Li, Farinacci & Traina                                   [Page 5]
  283.  
  284. RFC 1701          Generic Routing Encapsulation (GRE)       October 1994
  285.  
  286.  
  287.    is set to 1, then the Address Family field should be checked to
  288.    determine the semantics and use of the SRE Length, SRE Offset and
  289.    Routing Information fields.  The exact semantics for processing a SRE
  290.    for each Address Family is defined in other documents.
  291.  
  292.    Once all SREs have been processed, then the source route is complete,
  293.    the GRE header should be removed, the payload's TTL MUST be
  294.    decremented (if one exists) and the payload packet should be
  295.    forwarded as a normal packet.  The exact forwarding method depends on
  296.    the Protocol Type field.
  297.  
  298. Current List of Protocol Types
  299.  
  300.    The following are currently assigned protocol types for GRE.  Future
  301.    protocol types must be taken from DIX ethernet encoding.  For
  302.    historical reasons, a number of other values have been used for some
  303.    protocols.  The following table of values MUST be used to identify
  304.    the following protocols:
  305.  
  306.        Protocol Family                     PTYPE
  307.        ---------------                     -----
  308.        Reserved                            0000
  309.        SNA                                 0004
  310.        OSI network layer                   00FE
  311.        PUP                                 0200
  312.        XNS                                 0600
  313.        IP                                  0800
  314.        Chaos                               0804
  315.        RFC 826 ARP                         0806
  316.        Frame Relay ARP                     0808
  317.        VINES                               0BAD
  318.        VINES Echo                          0BAE
  319.        VINES Loopback                      0BAF
  320.        DECnet (Phase IV)                   6003
  321.        Transparent Ethernet Bridging       6558
  322.        Raw Frame Relay                     6559
  323.        Apollo Domain                       8019
  324.        Ethertalk (Appletalk)               809B
  325.        Novell IPX                          8137
  326.        RFC 1144 TCP/IP compression         876B
  327.        IP Autonomous Systems               876C
  328.        Secure Data                         876D
  329.        Reserved                            FFFF
  330.  
  331.    See the IANA list of Ether Types for the complete list of these
  332.    values.
  333.  
  334.    URL = ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers.
  335.  
  336.  
  337.  
  338. Hanks, Li, Farinacci & Traina                                   [Page 6]
  339.  
  340. RFC 1701          Generic Routing Encapsulation (GRE)       October 1994
  341.  
  342.  
  343. References
  344.  
  345.    RFC 1479
  346.       Steenstrup, M. "Inter-Domain Policy Routing Protocol
  347.       Specification: Version 1", RFC1479, BBN Systems and Technologies,
  348.       July 1993.
  349.  
  350.    RFC 1226
  351.       Kantor, B. "Internet Protocol Encapsulation of AX.25 Frames", RFC
  352.       1226, University of California, San Diego, May 1991.
  353.  
  354.    RFC 1234
  355.       Provan, D. "Tunneling IPX Traffic through IP Networks", RFC 1234,
  356.       Novell, Inc., June 1991.
  357.  
  358.    RFC 1241
  359.       Woodburn, R., and D. Mills, "Scheme for an Internet Encapsulation
  360.       Protocol: Version 1", RFC 1241, SAIC, University of Delaware, July
  361.       1991.
  362.  
  363.    RFC 1326
  364.       Tsuchiya, P., "Mutual Encapsulation Considered Dangerous", RFC
  365.       1326, Bellcore, May 1992.
  366.  
  367.    SDRP
  368.       Estrin, D., Li, T., and Y. Rekhter, "Source Demand Routing
  369.       Protocol Specification (Version 1)", Work in Progress.
  370.  
  371.    RFC 1702
  372.       Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing
  373.       Encapsulation over IPv4 networks", RFC 1702, NetSmiths, Ltd.,
  374.       cisco Systems, October 1994.
  375.  
  376. Security Considerations
  377.  
  378.    Security issues are not discussed in this memo.
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Hanks, Li, Farinacci & Traina                                   [Page 7]
  395.  
  396. RFC 1701          Generic Routing Encapsulation (GRE)       October 1994
  397.  
  398.  
  399. Acknowledgements
  400.  
  401.    The authors would like to acknowledge Yakov Rekhter (IBM) and Deborah
  402.    Estrin (USC) for their advice, encouragement and insightful comments.
  403.  
  404. Authors'  Addresses
  405.  
  406.    Stan Hanks
  407.    NetSmiths, Ltd.
  408.    2025 Lincoln Highway
  409.    Edison NJ, 08817
  410.  
  411.    EMail: stan@netsmiths.com
  412.  
  413.  
  414.    Tony Li
  415.    cisco Systems, Inc.
  416.    1525 O'Brien Drive
  417.    Menlo Park, CA 94025
  418.  
  419.    EMail: tli@cisco.com
  420.  
  421.  
  422.    Dino Farinacci
  423.    cisco Systems, Inc.
  424.    1525 O'Brien Drive
  425.    Menlo Park, CA 94025
  426.  
  427.    EMail: dino@cisco.com
  428.  
  429.  
  430.    Paul Traina
  431.    cisco Systems, Inc.
  432.    1525 O'Brien Drive
  433.    Menlo Park, CA 94025
  434.  
  435.    EMail: pst@cisco.com
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Hanks, Li, Farinacci & Traina                                   [Page 8]
  451.  
  452.